Products exist today that emulate disk I/O devices in a virtual machine setting. Likewise there are storage products that provide volumes to applications in distributed settings of all types. Both virtual disk and virtual storage products share many similar implementation challenges because both types of products create virtual runtime device personalities on top of what are perceived to be physical resources. They also share the same basic environments: an application context where I/O requests are received and processed and a system context where I/O actions are undertaken on the device layer.
In a hypervisor setting fundamental performance and integration problems arise because the system and application environments are not the same for disk emulation and volume storage products. Disk emulation device system context is in the hypervisor and its application space is the virtual machine kernel mode.
With volume storage, existing products are placed either in a host virtual machine as a modification of the physical resource backing the emulated device or in the guest virtual machine where it modifies the perceived physical device. In either case the volume storage product's system environment is the virtual machine kernel mode. The result of this situation is a performance sapping, cascaded software stack. Little information is passed back and forth on disk resource topologies and so tight I/O scheduling is impossible.
Further, large numbers of unnecessary and expensive context switches are made to satisfy the communication requirements of the boundary interface between volume storage and emulated device. This boundary is wholly an artifact of the awkward interplay between the two implementations. Little attempt has been made to date to reconcile the two products. Both products are complex and combining them will require storage management functionality in the hypervisor.
Putting additional function in the average modern hypervisor is ill-advised because its internal interfaces are poorly abstracted and addition of broader device emulation puts a strain on system definition and reliability.
There are a number of challenges to delivering volume storage to a virtual machine. These challenges fall into two categories, data transport and system management. Data transport challenges are experienced in two ways: I/O scheduling and system overhead.
With regard to I/O scheduling, volume storage subsystem must make multiple individual reads and writes on different physical devices in order to complete a single application I/O request. Performance suffers when there is skew between the completions of the disk I/O's. For this reason, commands for individual disks that are associated with an application volume request are made at the same time. When emulated devices are placed between the volume device and the physical hardware, unwanted rescheduling of individual disk I/O commands is possible. This can wreak havoc with performance even if all of the requests are coming from a single virtual machine. Worse still is the case of multiple virtual machines sharing space on the same set of disks. The proper scheduling of requests coming from multiple virtual machines is unmanageable for complex sharing arrangements, because the physical device scheduling layer has no knowledge of the volume device topology.